You can use your existing ROMs on the SSD, you just need to mount it first - easiest is from autostart.sh (which you can find at /opt/retropie/configs/all).
Since RetroPie expects each system to be under it's own directory in the roms folder, you should probably bind-mount your ROM folders under the existing system folder. Something like:

# mount the SSD first sudo mount /dev/sda1 /media/usb0 # make sure each system is in the place with mount --bind /media/usb0/NES_Games /home/pi/RetroPie/roms/nes mount --bind /media/usb0/SNES_Games /home/pi/RetroPie/roms/snes # etc.

You can go without the bind mount steps if you modify the es_systems.cfg, but I think it's easier to map existing folders via mount --bind if the folder names don't match.

The biggest issue IMHO is the filesystem's permissions. Since it's ext4, you'll inherit the existing permissions and you'll probably have issues if the pi user cannot read or write to the ROM folders. By default, in RetroPie save states and game saves (.srm) are saved in the ROM folder. That may pose a problem if the pi user cannot write there, though you can probably change the save location in the global retroarch.cfg file.

EmulationStation does not know (nor care) how the controller is connected, so there's nothing to configure there.

You can however pause the RA software during gameplay and resume it afterwards using the onstart/onend scripts for runcommand - see here.

Thanx @Fiddla01 Fiddla01 for the new threat that brought us a solution.

@mitu that saves me a lot of sleep.

Not perfekt but a way i can live with it

@fiddla01

Late reply, but confirming...

I wanted and did the same thing with the same result. I switched back to HDMI to composite video and audio converter and the system works well, again.

https://retropie.org.uk/forum/topic/29625/startup-audio-quality-is-bad-a-v-connectivity?_=1631181389467

Looks like a bad video cable.

@therealtitleist said in USB Ports not working Retropie 4.7.1 / Raspberry Pi4B:

Does that point to a hardware failure?

Most likely yes.

@hellothere don't want to leave this unanswered.

Prereq:
Have a USB drive or SSD with same or larger capacity than your SD card.
When using an SSD SATA to USB adapter make sure it is fully UASP to get max. transfer/access speed. Here are some hints [1] - also this site has more details as I do provide below.

It goes like this:

Make a full backup of your SD-card (eg. with Win32DiskImager (<- easiest), Clonezilla, ...) to your desktop PC. Put that backup at your USB drive / SSD (again using Win32Diskimager or the tool of your choice) on your desktop PC. Resize the USB partition (only if the USB drive is larger than SD card). Advise the pi to use a different partition after initial booting from /boot, handing over to the USB drive.

When you are done with the backup (Step 1 and 2 from above) attach both (SD card and USB drive) to the Rpi.
Remove any additional USB storage attached to the pi to avoid confusion.
Boot/Power up.
Nothing has changed up to this point.

Note: Following steps are the crucial part - but no worries you have a backup. If something derails, you can back out by using the backup.

Step 3: Optional: Resize the USB partition (if USB drive is larger than SD card).

SSH to your pi as user pi. Type

sudo su

Issue blkid /dev/sda*

blkid /dev/sda* /dev/sda: PTUUID="e006ca92-3704-44b9-a15f-bc56e2171825" PTTYPE="gpt" /dev/sda1: UUID="4832bb70-bb77-4a4a-9d68-5541559df133" TYPE="ext4" PARTUUID="9ec38a7c-ff79-413f-bddc-fc66de260c13"

Note the partition number /dev/sdN on the left which has the TYPE="ext4".

Run with that number resize2fs /dev/sdN (replace N with your number identified, most likely it will be 2).
Wait for process to finish.

Step 4: Advise the kernel to mount a different partition as "root-filesystem".

I underlined the items to REMOVE in RED and those to ADD in GREEN.

The red and green values are different on your machine. Use those. Not those from the example!

SSH to your pi as user pi. Type

sudo su

gets you root.

Issue blkid /dev/sda*
B1.jpg

Will give you a similar output as above.
Note down the value of PARTUUID of partition with TYPE="ext4" (in the example 9ec38a7c-ff79-413f-bddc-fc66de260c13). There should be only one with this type.

Edit fstab (with editor nano (<-- easiest) (or editor of your choice)):

mount /dev/sda1 /mnt # <-- this should be the same sdN as used in resize2fs, will mount the partition from the USB drive. nano /mnt/etc/fstab

You will find something like this:

B2a.jpg

These current PARTUUID point to partitions on your SD card.( You can verify it with blkid /dev/mmcblk0*)

The second entry has to be altered to contain the PARTUUID you noted down before. For example:

B2b.jpg

Again: Use your identified PARTUUID value.
You don't have to keep the lines starting with # (=comment)
Save the file.

Almost done: Then edit cmdline.txt, last step before rebooting:

nano /boot/cmdline.txt

You will find something like:

B3a.jpg

This instructs the kernel to look for the root filesystem at the partition PARTUUID, currently the SD card.

Make it read, change only the PARTUUID, leave everything else as is:

B3b.jpg

Save the file. Reboot... Drum roll, please!

After reboot, ssh to your pi, then check with mount command:

mount | grep sda

Should output something like:

/dev/sda1 on / type ext4 (rw,noatime)

That's it. Revel in your success.

[1] https://jamesachambers.com/raspberry-pi-4-usb-boot-config-guide-for-ssd-flash-drives/

@questionmark said in Splashscreen images not displaying | omxiv erroring out:

So will this cause performance to dip?

No, it will not.

@beldar I don't notice tearing with SNES, NES, Genesis, Neo Geo, or Playstation. But I do notice it on Mortal Kombat 2 arcade which does run at a funky refresh rate. I also noticed it very badly with lr-flycast. Soul Calibur, MKGold, and NFL Blitz all had really bad tearing.